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Abstract of FR 2791159 (A1) 

The invention concerns an architecture for securely 
accessing virtual objects (Obv?i?) distributed in 
systems connected to the Internet (Rl), and for 
obtaining an instance therefrom. Said access is 
performed, via a smart card (2a), through a "WEB" 
browser (10), The terminal (1) and the smart card 
(2a) comprise each a specific protocol layer (13. 
23a), The latter contains intelligent agents (132. 
232a1 ) for setting up two-way data exchange 
sessions, thereby enabling the smart card (2a) to 
have a "WEB" server functionality. The smart card 
(2a) also comprises intelligent agents, called script 
Imnsl.ilors. and ;i virtual file management system (8 ) 
co-operating with a specialised script translator 
intelligent agent 7). Each irtual object (Obv?i? )is 
associated with a virtual file of the virtual file 
management system (8).; The specialised intelligent 
agent (7) presents to the browser (10) the list of 
accessible virtual objects (Obv?i?) and generates 
methods for accessing said objects. 
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(54) PROCEDE D'ACCES A UN OBJET A L'AIDE D'UN NAVIGATEUR DE TYPE "WEB" COOPERANT AVEC UNE 
CARTE A PUCE ET ARCHITECTURE POUR LA MISE EN OEUVRE DU PROCEDE. 

(§7) L'invention concerne un procede et une architecture 
permettant d'acceder, de facon securisee, a des objets vir- 

tuels (ObVj) repartis dans des systemes connectes au re- ! v 
seau Internet (Rl), et d'en obtenir une instance. Cet acces 
s'effectue, via une carte a puce (2a), par I'intermediaire d'un 
navigateur de type " WEB " (1 0), Le terminal (1 ) et la carte 
a puce (2a) comprennent chacun une couche protocoiaire 
specifique (13, 23a). Cette derniere comprend des agents 
intelligents (132, 232a-|) pour I'etablissement de sessions 
d'echanges bidirectionnels de donnees, ce quipermet a la 
carte a puce (2a) de presenter une fonctionnalite de serveur 
" WEB ; '. La carte a puce (2a) comprend aussi des agents 
intelligents, dits traducteurs de scripts, et un systeme de 
gestion de fichier virtuel (8) cooperant avec un agent intelli- 
gent traducteur de scripts specialise (7). Chaque objet vir- 
tuel (ObVj) est associe a un fichier virtuel du systeme de 
gestion de fichier virtuel (8). L'agent intelligent specialise (7) 
presente au navigateur (10) la liste des objets virtuels ac- 
cessibles (Obv,) et genere des methodes d'acces a ces ob- 
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PROCEDE D'ACCES A UN OBJET A L'AIDE D'UN NAVIGATEUR DE TYPE 
"WEB" COOPERANT AVEC UNE CARTE A PUCE ET ARCHITECTURE 
POUR LA MISE EN CEUVRE DU PROCEDE. 

[.'invention concerne un procede d'acces a un objet a I'aide d'un navigateur de 
type "WEB" cooperant avec une carte a puce, plus particulierement d'acces a 
un objet qui sera appele virtuel ci-apres. 

L'invention concerne plus particulierement encore un procede d'acces 
securise aux objets precites. 

L'invention concerne egalement une architecture de mise en ceuvre d'un tel 
procede. 

Le navigateur "WEB" est compris dans une station d'utilisateur. Cette station 
d'utilisateur est connectee a un reseau de transmission de donnees, et 
notamment de type Internet. 

Dans le cadre de l'invention, le terme "objet" doit etre considere dans son sens 
le plus general. II englobe de nombreux types de ressources informatiques, tels 
que des fichiers textes, des fichiers images ou des fichiers multimedias (video, 
son, etc.). II englobe egalement des transactions ou des connexions a un 
systeme informatique, selon un protocole donne. 

Dans le premier cas, on parlera ci-apres d'objets statiques, car leur instance 
ne depend pas du temps. Dans le second cas, on parlera d'objets dynamiques, 
car leur instance varie en fonction du temps. On peut citer, a titre d'exemple 
non limitatif, dans le cadre d'un reseau de type Internet, une connexion de type 
•Telnet". 

Toujours dans le cadre de l'invention, le terme "station d'utilisateur" 
doit etre compris dans un sens general. La station d'utilisateur precitee peut 
etre notamment constitute par un ordinateur personnel fonctionnant sous 
divers systemes d'exploitation, tels WINDOWS ou UNIX (tous deux etant des 
marques deposees). Elle peut etre aussi constitute par une station de travail, 
un ordinateur portable ou un terminal de carte, dit dedie. 
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De meme, dans le cadre de I'invention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers I'exterieur, 
du type dit "extranet", de facon generale tout reseau dans lequel les echanges 
de donnees s'effectuent selon un protocole du type Internet. 
Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se placera 
dans le cadre de I'application preferee de I'invention, sauf mention contraire. 
On considerera done une station d'utilisateur, que Ton appellera simplement 
"terminal", munie d'un lecteur de carte a puce et connecte a un reseau de type 
Internet. 

Un systeme d'application a base de carte a puce comporte generalement les 
elements principaux suivants : 
une carte a puce ; 

un systeme note constituant le terminal precite ; 

un reseau de communication, a savoir le reseau Internet dans 
I'application preferee ; 

et un serveur d'application connecte au reseau. 
La figure 1A illustre schematiquement un exemple d'architecture de ce type. 
Le terminal 1, par exemple un ordinateur individuel, comporte un lecteur 3 de 
carte a puce 2. Ce lecteur 3 peut etre ou non physiquement integre dans le 
terminal 1. La carte a puce 2 comporte un circuit integre 20 dont des 
connexions d'entrees-sorties affleurent en surface de son support pour 
autoriser une alimentation en energie electrique et des communications avec le 
terminal 1. Ce dernier comprend des circuits d'acces a un reseau de 
transmissions de donnees Rl. Ces circuits dependent, notamment, de la nature 
du reseau Rl et du terminal 1. A titre d'exemple, il peut s'agir d'une carte 
reseau pour un reseau de type local ou d'un modem pour se connecter a une 
ligne telephonique commutee ou a un reseau numerique a integration de 
services ("RNIS"), pour se connecter au reseau Internet, par exemple via un 
prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). 
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Le terminal 1 comprend naturellement tous les circuits et organes necessaires 
a son bon fonctionnement, et qui n'ont pas ete represents dans un but de 
simplification du dessin : unite centrale, memoires vive et fixe, memoire de 
masse a disque magnetique, lecteur de disquette et/ou de CedeRom, etc. 
Habituellement, le terminal 1 est aussi relie a des peripheriques classiques, 
integres ou non, tels un ecran de visualisation 5 et un clavier 6. 
Le terminal 1 peut etre mis en communication avec des serveurs ou tous 
systemes informatiques connectes au reseau Rl, dont un seul, 4, est illustre sur 
la figure 1A. Dans le cas de ('application preferee de I'invention, les circuits 
d'acces 1 1 mettent le terminal 1 en communication avec les serveurs 4 grace a 
un logiciel particulier 10, appele navigateur de type "WEB", ou "browser" selon 
la terminologie anglo-saxonne. Celui-ci permet d'acceder a diverses 
applications reparties sur I'ensemble du reseau Rl, generalement selon un 
mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocoles repondant a des standards comprenant 
plusieurs couches logicielles superposees. Dans le cas d'un reseau Rl de type 
Internet, les communications s'effectuent selon des protocoles specifiques a ce 
type de communications, qui seront detailles ci-apres, mais qui comprennent 
egalement plusieurs couches logicielles. Le protocole de communication est 
choisi en fonction de ['application plus particulierement visee : interrogation de 
pages "WEB", transferts de fichiers, courrier electronique (e-mel, ou "e-mail" 
selon la terminologie anglo-saxonne), forums ou nouvelles ("news" selon la 
terminologie anglo-saxonne), etc. 

L'architecture logique du systeme comprenant un terminal, un lecteur de carte 
a puce et la carte a puce, est representee schematiquement par la figure 1B. 
Elle est decrite par la norme ISO 7816, qui elle-meme comportent plusieurs 
sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le marquage 
des cartes ; 
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ISO 7816-3, en ce qui concerne le transfert de donnees entre le terminal 
et la carte a puce ; et 

ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et le format 
des commandes. 

Sur la figure 1B, du cote terminal 1, on n'a represents que les couches 
repondant a la norme ISO 7816-3, references 101, et le gestionnaire d'ordres 
"APDU" (norme ISO 7816-4), reference 102. Du cote carte a puce 2, les 
couches repondant a la norme ISO 7816-3 sont referencees 200 et le 
gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est reference 201. Les 
applications sont referencees Ai, .... Aj, An ; n etant le nombre maximum 
duplications presentes sur la carte a puce 2. 

Une application "cardlet", Aj, presente dans la carte a puce 2 (figure 1A), 
dialogue avec le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente 
typiquement des ordres d'ecriture et des ordres de lecture. Le format des 
ordres est connu sous I'abreviation anglo-saxonne de "APDU" (pour 
"Application Protocol Data Unit"). II est defini par la norme ISO 7816-4 precitee. 
Un "APDU" de commande est note "APDU. command' et un "APDU" de 
reponse est note "APDU. response". Les "APDU" sont echanges entre le lecteur 
de carte et la carte a puce au moyen d'un protocole specifie par la norme ISO 
7816-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

Lorsque la carte a puce 2 inclut plusieurs applications distinctes, comme 
illustre sur la figure 1B, on parle de carte multi-applicative. Cependant, le 
terminal 1 dialogue avec une seule application a la fois. Une application A\ se 
presente, par exemple, sous la forme d'une piece de logicielle, dite "applet", en 
langage "JAVA" (marque deposee), que Ton appellera ci-apres "cardlet". La 
selection d'un "cardlet" particulier A\ est obtenu a I'aide d'un "APDU" du type 
selection ("SELECT'). Une fois ce choix effectue, les "APDU" qui le suivent 
sont achemines vers ce "cardlet". Un "APDU SELECT" nouveau a pour effet 
d'abandonner Papplication en cours et d'en choisir une autre. Le sous- 
ensemble logiciel gestionnaire des "APDU" 201 permet de choisir une 
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application particuliere A\ dans la carte a puce 2, de memoriser I'application 
ainsi choisie, et de transmettre et/ou recevoir des "APDU" vers et depuis cette 
application. 

En resume de ce qui vient d'etre decrit, la selection d'une application A; et le 
dialogue avec celle-ci s'effectue par echanges d'ordres "APDU". On suppose 
que les applications Aj sont des applications conventionnelles, que Ton 
appellera ci-apres "GCA" (pour "Generic Card Application" ou application de 
carte generique). 

Dans un systeme d'applications a base de carte a puce, comme illustre par 
I'architecture de la figure 1B, cette derniere peut se voir devolu diverses 
fonctions, notamment des fonctions de securite. II est en effet avantageux de 
stocker les donnees liees a la securite (mots de passe, droits d'acces, etc.) 
dans une carte a puce qui peut etre conservee par I'utilisateur. En outre les 
donnees etant enregistrees dans une memoire fixe, sous une forme qui peut 
etre chiffree, elles ne sont pas facilement modifiables, ni meme directement 
lisibles de I'exterieur. 

Cependant, il est a noter que la carte 3 ne peut communiquer directement 
avec les navigateurs du commerce, sauf a modifier le code de ces derniers. 
Les cartes a puce actuelles, qui par ailleurs sont conformes aux standards 
rappeles ci-dessus, ont une configuration materielle et logicielle qui ne permet 
pas non plus de communiquer directement avec le reseau Internet. En 
particulier, elles ne peuvent recevoir et transmettre des paquets de donnees, 
selon Tun ou I'autre des protocoles utilises sur ce type de reseau. II est done 
necessaire de prevoir une piece de logiciel additionnelle, implantee dans le 
terminal 1, generalement sous la forme de ce qui est appele un "plug-in", selon 
la terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 
12 sur la figure 1A, effectue I'interface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 
Dans I'etat actuel de la technique, le systeme note associe au lecteur de carte 
3, e'est-a-dire le terminal 1, est associe egalement a une application 
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particuliere. En d'autres termes, il est necessaire de prevoir un terminal 
specifique, dit "dedie", pour chaque application particuliere. 
En outre, il est clair que, meme compte tenu de la rapide evolution passee des 
technologies et de leur evolution future previsible, la capacite d'enregistrement 
d' informations dans des circuits de memoire, vive ou fixe, d'une carte a puce 
reste et restera tres limitee, si on compare cette capacite a celle offerte par un 
terminal "hote" de cette carte a puce, et naturellement a celles offertes par des 
systemes plus importants, "mini-ordinateurs" ou grands systemes de type dit 
"main frame". Aussi, il n'est pas possible de stocker les donnees d'un nombre 
important duplications dans une carte a puce, et notamment des fichiers de 
type multimedia tres volumineux. 

L'invention vise a pallier les inconvenients des dispositifs de I'art connu et dont 
certains viennent d'etre rappeles, tout en repondant aux besoins qui se font 
sentir. II doit notamment etre possible d'acceder a un grand nombre 
duplications, meme volumineuses d'un point de vue quantite de donnees, de 
natures diverses et reparties sur tout le reseau Internet. En outre, dans un 
mode de realisation prefere, les acces doivent beneficier d'une securite 
maximale, c'est-a-dire dans la pratique s'effectuer via et sous le controle d'une 
carte a puce contenant toutes les donnees necessaires a la securisation des 
echanges de donnees. Enfin, ces acces doivent pouvoir s'effectuer a partir d'un 
navigateur du commerce et etre transparents pour un utilisateur, qui ne doit 
"voir" que la carte a puce comme unique interlocuteur, quel que soit le lieu de 
stockage de ('application. 

Selon une premiere caracteristique importante du procede, la carte a puce 
presente au systeme hote, c'est-a-dire le terminal, un modele de terminal 
virtuel, par exemple sous la forme d'une page en langage "HTML" (pour 
"HyperText Markup Language"), ou plus generalement en langage hypertexte, 
ou encore sous la forme d'un "applet", en langage "JAVA" (marque deposee), 
ce qui permet a I'utilisateur de choisir une application particuliere parmi celles 
disponibles et proposees par la carte a puce. De ce fait, le terminal se trouve 
done banalise et supporte une pluralite d'applications. Le systeme hote est vu 
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comme un peripherique de la carte a puce, et il met a sa disposition des 
ressources materielles, tels un ecran de visualisation, un clavier, etc. 
Pour ce faire, on prevoit une couche de logiciel de communication specifique 
dans la carte a puce et son pendant dans le terminal. Le terme "specifique" doit 
etre entendu comme specifique au procede de I'invention. En effet, ces 
couches de communications, dites specifiques, sont banalisees quelle que soit 
I'application consideree. Elles n'interviennent que dans le processus d'echange 
de donnees bidirectionnel entre la carte a puce et le terminal, d'une part, et la 
carte a puce et le reseau. 

Les couches logicielles de communication specifiques comprennent 
notamment des composants logiciels, dits "agents intelligents", permettant en 
particulier des conversions de protocoles. II existe des agents intelligents 
appareilles dans les couches de communication specifiques respectives 
associees au terminal et a la carte a puce. Selon le procede de I'invention, il 
s'etablit des sessions entre agents intelligents appareilles. 

Selon une deuxieme caracteristique importante, le procede de I'invention rend 
possible I'activation d'applications de type conventionnel, c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir les modifier en 
quoi que ce soit. 

Pour ce faire, on prevoit un ou plusieurs agents intelligents dits 
traducteurs de script, qui recoivent des requetes d'un navigateur et les 
traduisent en ordres "APDU" comprehensibles par I'application de type "CGA". 
Cette caracteristique technique permet d'implanter dans une carte a puce, dont 
I'architecture est conforme au procede de I'invention, un mecanisme similaire a 
la fonction dite "CGI" (pour "Common Gateway Interface") implantee dans les 
serveurs "WEB" classique. 

Enfin, selon Tune des caracteristiques les plus importantes du procede 
de I'invention, en mettant en oeuvre les fonctions et mecanismes precites, 
celui-ci permet d'acceder a des ressources informatiques reparties sur un 
reseau de transmission de donnees auquel est connecte le terminal, 
notamment le reseau Internet ou un reseau de type equivalent (intranet, 
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extranet), sans que I'utilisateur ait a se soucier de leurs emplacements. Dans 
ce qui suit, comme il a ete indique, ces ressources seront appelees "objets 
virtuels", statiques ou dynamiques. 

Pour ce faire, il est mis en ceuvre un agent intelligent traducteur de 
script dedie a cette tache, cooperant avec les autres agents intelligents 
presents dans le terminal et/ou la carte a puce. Cet agent permet de definir les 
objets virtuels auxquels la carte a puce peut acceder, et de ce fait egalement 
I'utilisateur (ou porteur de la carte a puce), d'une part, et fournit au navigateur 
interrogateur, via la carte a puce, des methodes permettant d'acceder a ces 
objets virtuels d'autre part. 

L'invention a done pour objet principal un procede pour acceder a un objet 
localise dans un systeme informatique connecte a un reseau de type Internet 
par I'intermediaire d'un navigateur de type "WEB", ledit navigateur etant 
compris dans un terminal, muni d'un lecteur de carte a puce et connecte audit 
reseau de type Internet, caracterise en ce qu'il comprend au moins les phases 
suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans ladite carte 
a puce, une premiere piece de logiciel, constituant une couche protocolaire de 
communication specifique ; 

bl une deuxieme phase preliminaire consistant a implanter, dans ledit 
terminal, une seconde piece de logiciel, constituant une couche protocolaire de 
communication specifique et formant interface avec au moins ledit navigateur 
"WEB" ; 

en ce que lesdites premiere et seconde pieces de logiciel specifique 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees, chacune desdites entites cooperant Tune avec I'autre de maniere a 
permettre I'etablissement d'une session d'echanges de donnees bidirectionnels 
entre ledit terminal et ladite carte a puce, de maniere a ce que ladite carte a 
puce offre la fonctionnalite d'un serveur "WEB" ; 

en ce qu'il est procede a une troisieme phase preliminaire consistant en 
I'implantation dans ladite carte a puce d'un systeme de gestion de fichiers dit 
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virtuel, organist en repertoires, sous-r6pertoires et fichiers 6lementaires, une 
partie au moins desdits fichiers elementaires etant constitues par des fichiers 
6lementaires dits virtuels assoctes chacun a I'un desdits objets et contenant 
des donnees de description permettant au moins de localiser celui-ci et de 
gSnerer des donnees de methode d'acces ; 

en ce qu'il comprend une quatrieme phase preliminaire consistant a 
implanter d'au moins une deuxieme entite logicielle, apte a interpreter une suite 
^instructions et a la traduire en une suite d'ordres, de maniere a cooperer avec 
ledit systeme de gestion de fichiers virtuel et ladite seconde piece de logiciel 
specifique ; 

et en ce qu'il comprend au moins les etapes suivantes : 
1/ etablissement d'une session d'echanges de donnees entre ledit terminal 
et ladite carte a puce, par I'intermediaire d'une desdites paires de premieres 
entites logicielles appariees, de maniere a transmettre une requete destinee a 
ladite deuxieme entite logicielle cooperant avec ledit systeme de gestion de 
fichiers dit virtuel ; 

21 Elaboration et transmission audit navigateur "WEB", par I'intermediaire de 
ladite deuxi&ne entity logicielle, et via lesdites premiere et seconde pieces de 
logiciel, formant lesdites couches protocolaires de communication specifiques, 
d'une reponse a ladite requete comprenant une liste desdits objets accessibles 
via ladite carte a puce ; 

3/ selection par ledit navigateur "WEB" d'un desdits objets accessibles et 
envoi a ladite deuxieme entite logicielle d'une requete supplementaire pour 
obtenir une instance de celui-ci dans ledit terminal ; 

41 generation par cette ladite entite logicielle desdites donnees de methode 

d'acces, en fonction desdites donnees de description ; et 

5/ recherche dudit objet par utilisation desdites donnees de localisation et 

de methode d'acces, et creation d'une instance de cet objet dans ledit terminal. 

L'invention a encore pour objet une architecture pour la mise en oeuvre de ce 

procedS. 
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[.'invention va maintenant etre decrite de facon plus detaillee en se referant 
aux dessins annexes, parmi lesquels : 

les figures 1A et 1B illustrent schematiquement les architectures 
materielles et logiques, respectivement, d'un exemple de systeme d'application 
a base de carte a puce selon I'art connu ; 

la figure 2 illustre schematiquement un exemple de systeme d'application 
a base de carte a puce selon I'invention, cette derniere agissant en tant que 
serveur "WEB" ; 

la figure 3 illustre de facon simplifiee I'architecture logique d'un systeme 
dans lequel la carte a puce comprend des agents intelligents ; 

la figure 4 illustre une architecture de systeme conforme a I'invention, 
dans laquelle la carte a puce comprend des agents intelligents traducteurs de 
scripts ; 

la figure 5 est un diagramme illustrant schematiquement les principals 
phase d'echanges entre un navigateur et une carte a puce presentant 
I'architecture de la figure 4 ; 

la figure 6 est un diagramme illustrant schematiquement un aspect 
essentiel du precede selon I'invention par lequel il est possible d'acceder a des 
objets virtuels repartis sur un reseau de type Internet via une carte a puce et un 
navigateur de type "WEB" ; 

la figure 7 illustre schematiquement I'organisation d'un systeme de 
gestion de fichiers dit virtuel pour la mise en oeuvre de cet aspect du precede 
de I'invention ; 

la figure 8 est un exemple d'architecture comprenant un systeme de 
gestion de fichier virtuel selon la figure 7 ; 

les figures 9 a 15 sont des diagrammes illustrant schematiquement 
plusieurs mode de realisation du precede selon I'invention. 
Avant de decrire le precede d'activation d'applications localisees dans une 
carte a puce selon I'invention et de detainer une architecture pour sa mise en 
oeuvre, il apparalt tout d'abord utile de rappeler brievement les caracteristiques 
principales des protocoles de communication sur les reseaux. 
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L'architecture des reseaux de communication est decrite par diverses 
couches. A titre d'exemple, le standard "OSI" ("Open System Interconnection"), 
defini par I' "ISO", comporte sept couches qui vont des couches dites basses 
(par exemple la couche dite "physique" qui concerne le support de 
transmission physique) aux couches dites hautes (par exemple la couche dite 
d' "application"), en passant par des couches intermediaires, notamment la 
couche dite de "transport". Une couche donnee offre ses services a la couche 
qui lui est immediatement superieure et requiert de la couche qui lui 
immediatement inferieure d'autres services, via des interfaces appropriees. Les 
couches communiquent a I'aide de primitives. Elles peuvent egalement 
communiquer avec des couches de meme niveau. Dans certaines 
architectures, I'une ou I'autre de ces couches peut etre inexistante. 
Dans un environnement de type Internet, les couches sont au nombre de cinq, 
et de facon plus precise, en allant de la couche superieure a la couche 
inferieure : la couche d'application ("http", "ftp", "e-mail", etc.), la couche de 
transport ('TCP"), la couche d'adressage de reseau ("IP"), la couche de liens 
de donnees ("PPP", "Slip", etc.) et la couche physique. 
Ces rappels etant effectues, on va maintenant decrire une architecture de 
systeme d'application a base de carte a puce autorisant celle-ci a agir comme 
un serveur "WEB". Un exemple d'une telle architecture est represents 
schematiquement sur la figure 2. Les elements communs aux figures 1A et 1B 
portent les memes references et ne seront re-decrits qu'en tant que de besoin. 
Pour simplifier le dessin, on n'a pas represents les divers peripheriques 
connectes au terminal (figure 1A : ecran 5 et clavier 6, par exemple). 
A I'exception de couches logicielles de protocole de communication 
specifiques, referencees 13 et 23a, respectivement implantees dans le terminal 
1 et la carte a puce 2a, les autres elements, materiels ou logiciels, sont 
communs a I'art connu. 

Le terminal 1 comprend des circuits 1 1 d'acces au reseau Rl, constitues par 
exemple d'un modem pour le reseau Internet ou d'une carte reseau pour un 
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reseau local. Ces circuits regroupent les couches logicielles inferieures Ci et 
C2, correspondant aux couches "physique" et de "lien de donnees". 
On a egalement represents les couches superieures C3 et C4, correspondant 
aux couches "d'adressage de r§seau" ("IP", dans le cas d'lnternet) et de 
"transport" ('TCP"). La couche sup6rieure d'application ("http", "ftp", "e-mail", 
etc.) n'a pas ete representee. 

L'interface entre les couches inferieures, C1 et C2, et les couches 
superieures, C3 et C4, est constitute par une couche logicielle g6neralement 
appelee "driver couches basses". Les couches superieures, C3 et C4, 
s'appuient sur cette interface et sont mises en ceuvre par I'intermediaire de 
bibliotheques de fonctions specifiques ou bibliotheques reseau 14, avec 
lesquelles elles correspondent. Dans le cas du reseau Internet, 'TCP/IP" est 
mis en ceuvre au moyen de bibliotheques dites de "sockets". 

Cette organisation permet a un navigateur 10 (figure 1A) de poser des 
requetes vers un serveur 4 (figure 1A), pour la consultation de pages "WEB" 
(protocole "HTTP"), pour le transfert de fichiers (protocole "FTP") ou renvoi de 
courrier electronique (protocole "e-mail"), ce de facon tout a fait classique. 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou non. Pour 
communiquer avec la carte a puce 2a, le lecteur de carte englobe egalement 
deux couches basses, CC1 (couche physique) et CC2 (couche de lien de 
donnees), jouant un r&le similaire aux couches C1 et C2. Les interfaces 
logicielles avec les couches CC1 et CC2 sont decrites, par exemple, par la 
specification "PC/SC" ("part 6, service provider"). Les couches elles-memes, 
CC1 et CC2, sont notamment decrites par les normes ISO 7816-1 a 7816-4, 
comme il a ete rappele. 

Une couche logicielle supplemental 16 forme interface entre les couches 
applicatives (non representees) et les couches inferieures, CC1 et CC2. La 
fonction principale devolue a cette couche est une fonction de 
multiplexage/demultiplexage. 
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Les communications avec la carte a puce 2a s'effectuent selon un paradigms 
similaire a celui utilise pour la manipulation de fichiers dans un systems 
Sexploitation du type "UNIX" (marque deposee) : OUVRIR ("OPEN"), LIRE 
("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation similaire, a savoir 
la presence de deux couches basses, referencees CCai (couche physique) et 
CCa2 (couche de lien de donnees), ainsi qu'une couche d'interface 26a, tout a 
fait similaire a la couche 16. 

Selon une premiere caracteristique importante, on prevoit, de part et d'autre, 
c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux couches de 
protocoles specifiques : 13 et 23a, respectivement. 

Dans le terminal 1, la couche specifique 13 s'interface aux "drivers couches 
basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et aux 
couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
specifique 13 permet le transfert des paquets reseaux de et vers la carte a 
puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10 (figure 2), le courrier electronique, etc., pour des utilisations mettant 
en ceuvre la carte a puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a fait similaire 
constituee par une instance supplemental de la couche specifique, 
referenced 23a, pendant de la couche 13. 

De facon plus precise, les couches specifiques, 13 et 23a, sont subdivisees en 
trois elements logiciels principaux : 

- un module, 130 ou 230a, de transfert de blocs d'informations entre les 
couches 13 et 23a, via les couches conventionnelles CC1, CC2, CCai et CCa2 

- une ou plusieurs pieces de logiciel, dites "agents intelligents", 132 ou 
232a, qui realisent, par exemple, des fonctions de conversion de protocoles ; 

- et un module de gestion de la configuration specifique, 131 et 231a, 
respectivement ; module qui peut etre assimile a un agent intelligent particulier. 
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On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 
Les couches de niveau deux (couches de lien de donnees), CC2 et CCa2, 
assurent I'echange entre la carte a puce 2a et le terminal 1 . Ces couches sont 
responsables de la detection et I'eventuelle correction d'erreurs de 
transmission. Differents protocoles sont utilisables, et a titre d'exemples non 
exhaustifs les suivants : 

- la recommandation ETSI GSM 11.11 ; 

- le protocole defini par la norme ISO 7816-3, en mode caractere T=0 ; 

- le protocole defini par la norme ISO 7816-3, en mode bloc T=1 ; 

- ou le protocole defini par la norme ISO 3309, en mode trame "HDLC" 
(pour "High-Level Data Link Control procedure" ou procedure de commande de 
liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole ISO 7816- 
3, en mode bloc. 

De facon connue en soi, a chaque couche de protocole, il est associe un 
certain nombre de primitives qui permettent les echanges de donnees entre 
couches de meme niveau et d'une couche a I'autre. A titre d'exemple, les 
primitives associees a la couche de niveau deux sont du type "demande de 
donnees" {"Data, request') et "envoi de donnees" par la carte 
("Data.response"), ainsi que "confirmation de donnees" ("Data.confirm"), etc. 
De facon plus specifique, les couches 13 et 23a sont chargees du dialogue 
entre la carte a puce 2a et I'hote, e'est-a-dire le terminal 1. Ces couches 
permettent I'echange d' informations entre un utilisateur (non represents) du 
terminal 1 et la carte a puce 2a, par exemple via des menus deroulants sous la 
forme d'hypertexte au format "HTML". Elles permettent aussi la mise en place 
d'une configuration adaptee pour remission et/ou la reception de paquets de 
donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois entites 
distinctes. 
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La premiere couche, 130 ou 230a, est essentiellement constitute par un 
multiplexeur logiciel. Elle permet I'echange d'informations entre la carte a puce 
2a et le terminal hote 1, sous la forme d'unites de donnees de protocole. Elle 
joue un r&le similaire a celui d'un commutateur de paquets de donnees. Ces 
unites sont emises ou recues via la couche de niveau 2 (couche de liens de 
donnees). Ce protocole particulier de communication permet de mettre en 
communication au moins une paire d' "agents intelligents". Le premier agent de 
chaque paire, 132, est situe dans la couche 13, c6te terminal 1, le second, 
232a, est situe dans la couche 23a, cote carte a puce 2a. Une liaison entre 
deux "agents intelligents" est associee a une session. Une session est un 
echange de donnees bidirectionnel entre ces deux agents. 

Un agent intelligent peut realiser tout ou partie de fonctions des couches de 
niveau trois et quatre, en fonction de la configuration mise en ceuvre par le 
terminal 1 . 

Un agent intelligent particulier est identifie avantageusement par un nombre 
entier, par exemple sur 16 bits (nombre compris entre 0 et 65535). Cet 
identificateur est utilise, par exemple, dans une unite de donnee de protocole 
constituant une reference de destination et une reference de source. 

II existe deux grandes categories d'agents intelligents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
"client", qui sont identifies par une reference variable, delivree par le module 
de gestion de configuration, 131 ou 231a. 

Le processus d'ouverture d'une session est habituellement le suivant : un 
agent intelligent de type "client" ouvre la session vers un agent intelligent de 
type "serveur". Les couches 130 et 230a gerent des tables (non representees) 
qui contiennent la liste des agents intelligents presents, cfite terminal hote 1 et 
carte a puce 2a. 

Les agents intelligents sont associes a des proprietes ou attributs particuliers. 
Pour fixer les idees, et a titre d'exemple non limitatif, les six proprietes 
suivantes sont associees aux agents intelligents : 
"hote" : agent localise dans le terminal ; 



2791159 



16 

"carte" : agent localise dans la carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 

"reseau" : agent communiquant avec le reseau ; 

"client" : agent qui initialise une session ; 

"serveur" : agent qui recoit une demande de session. 
Les agents intelligents permettent d'echanger des donnees (de I'hypertexte 
par exemple), mais egalement de declencher des transactions reseau. 
Les modules de gestion de configuration, 131 et231a, respectivement, sont 
assimilables, comme il a ete indique, a des agents intelligents particuliers. Par 
exemple, le module 131, cote terminal hotel, gere notamment des 
informations relatives a la configuration de ce terminal (modes de 
fonctionnement), liste des autres agents intelligents presents, etc. Le module 
231a, cote carte a puce 2a, a des fonctions analogues. Ces deux agents 
intelligents peuvent etre mis en communication Tun avec I'autre pour etablir 
une session. 

Selon une caracteristique importante, la carte a puce 2a propose au systeme 
hote, c'est-a-dire au terminal 1, un modele de terminal virtuel. Pour ce faire, la 
carte a puce 2a se comporte comme un serveur "WEB". 

La carte a puce 2a est "adressee" par le navigateur 10. Elle lui transmet alors 
une page de type "WEB" en langage "HTML", un "applet" ou toute autre piece 
de logiciel. A titre d'exemple, la page "WEB" peut se presenter sous la forme 
d'une page d'accueil donnant un choix duplications possibles et/ou 
d'hyperliens vers des serveurs exterieurs. 

De facon pratique, la carte a puce 2a est avantageusement "adressee" par 
utilisation d'une adresse "URL" (pour "Universal Resource Locator") definissant 
un rebouclage sur le terminal 1 lui-meme, et non un pointage sur un serveur 
externe. A titre d'exemple, la structure de cette "URL" est habituellement la 
suivante : 

http://1 27.0.0. 1:8080 (1), 
dans lequelle 127.0.0.1 est I'adresse "IP" de rebouclage et 8080 est le numero 
de port. 
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La figure 3 illustre de facon simplifiee I'architecture logique d'un systeme dont 
la carte a puce 2a comprend des agents intelligents, dont deux seulement ont 
ete represents : un agent intelligent de type non precisement defini 232a2 et 
un agent intelligent 232ai , de type dit "WEB". La pile logique comprend, les 
couches de protocole inferieures, referencees 200a, repondant aux normes 
ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire de commandes "APDU" 
201 ai, et le multiplexeur de paquets230a, ce dernier etant interface aux 
agents intelligents, notamment I'agent intelligent "WEB" 232ai . 

Du cote terminal, il existe deux piles, Tune communiquant avec le reseau 
Internet Rl, I'autre avec la carte a puce 2a. La premiere pile comprend les 
organes 11 (figure 2 : Ci et C2) d'acces au reseau (normes OSI 1 et 2) et les 
couches de protocole "TCP/IP" (figure 2 : C3 et C4), referencees 100. Ces 
dernieres couches sont interfacees avec le navigateur "WEB" 10. L'autre pile 
comprend les couches de protocole inferieures, referencees 101, repondant 
aux normes ISO 7816-3 (figure 2 : C1 et C2), le gestionnaire 102 d'ordres 
"APDU" et le multiplexeur de paquets 130, ce dernier etant interface avec des 
agents intelligents, dont un seul 132, est represents. Ce dernier, que Ton 
supposera de "type reseau", peut en outre communiquer, d'une part avec le 
navigateur 10, via les couches 'TCP/IP" 100, d'autre part avec le reseau 
Internet Rl, via ces memes couches 'TCP/IP" 100 et I'organe 11, d'acces au 
reseau Rl. 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec une ou 
plusieurs couches de niveau applications, que Ton appellera simplement 
applications. Ces applications sont, comme il a ete indique, des applications de 
type conventionnel, que Ton a appele "cardlet". 

En resume, la fonction "serveur WEB", fournie par la carte a puce 2a, peut 
etre realisee par I'association de I'agent intelligent "WEB" 232ai dans la carte 
a puce et de I'agent reseau 132 dans le terminal 1. 

La carte a puce 2a presente done bien la fonctionnalite serveur "WEB". En 
outre, selon une caracteristique importante du procede de I'invention, n'importe 
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quelle application conventionnelle, A-\ a An, du type "CGA" precite, peut etre 
activee au travers de ce serveur "WEB", soit par le navigateur "WEB" 10 
present dans le terminal 1, soit par un navigateur eloigne, localise en un point 
quelconque du reseau Internet Rl. Selon le precede de I'invention, les 
applications, Ai a An, ne necessitent pas d'etre re-ecrites et sont mises en 
oeuvre telles quelles. 

Selon une autre caracteristique de I'invention, ces applications restent 
accessibles a un terminal de type conventionnel, c'est-a-dire conforme a I'art 
connu. 

Pour repondre h ces exigences, la fonction serveur "WEB", offerte par la carte 
a puce 2a, inclut un mecanisme similaire a la fonction dite "CGI" (pour 
"Common Gateway Interface") implantee dans les serveurs "WEB" classiques. 

Avant de decrire un exemple d'architecture conforme a I'invention, permettant 
de realiser une fonction de ce type, au sein meme de la carte a puce, il est utile 
de rappeler les principales caracteristiques d'un mode de fonctionnement 
"CGI". 

Le "CGI" est une specification de mise en ceuvre, depuis un serveur "WEB", 
d'applications ecrites pour les systemes d'exploitation "UNIX" (marque 
deposee), "DOS", ou "WINDOWS" (marque deposee). A titre d'exemple, pour 
le systeme d'exploitation "UNIX", la specification est "CG1 1.1" et pour le 
systeme d'exploitation "WINDOWS 95", la specification est "CG1 1.3". 

Toujours a titre d'exemple, une requete "HTTP" du type : 

"http://www.host.com/cgi-bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), est 
interpr&ee par un serveur "WEB" comme I'execution d'un script de commande, 
de type "CGI" nomine "xxx" et present dans le repertoire "cgi-bin" de ce 
systeme h&te. Bien que le nom du repertoire puisse etre a prion quelconque, 
par convention, c'est le nom donne au repertoire stockant les scripts de type 
"CGI". Un script est une suite d'instructions du systeme d'exploitation du 
systeme hote dont le resultat final est transmis au navigateur "WEB" emetteur 
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de la requete precitee. Differents langages peuvent etre utilises pour ecrire ce 
script, par exemple le langage "PERL" (marque deposee). 
De facon pratique, la requete est habituellement affichee sur un ecran 
informatique sous la forme d'un formulaire compris dans une page "HTML". Le 
langage "HTML" permet de traduire un formulaire en une adresse "URL". Le 
formulaire comporte un ou plusieurs champs, obligatoires ou non, qui sont 
remplis par un utilisateur a I'aide des moyens de saisie habituels : clavier pour 
le texte, souris pour les cases a cocher ou les boutons dits "radio", etc. Le 
contenu du formulaire (ainsi qu'eventuellement des informations et instructions 
dites "cachees") est emis a destination du serveur "WEB". Le code "HTML" de 
la page decrit la structure materielle du formulaire (cadre, graphisme, couleur, 
et tout autre attribut), ainsi que la structure des champs de donnees a saisir 
(nom, longueur, type de donnees, etc.). 

La transmission peut s'effectuer selon deux types de formats principaux. Un 
premier format utilise la methode dite "POST 1 et un second la methode dite 
"GET 1 . Une information de type de format est presente dans le code de la page 
formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une carte a 
puce, meme si celle-ci offre la fonctionnalite serveur "WEB" conformement a 
Tune des caracteristiques de I'invention. 

On va maintenant decrire un exemple d'architecture permettant d'activer une 
application quelconque, de type conventionnel, via un serveur "WEB" sur la 
carte a puce 2a, par reference a la figure 4. 

Lors d'une premiere etape, un utilisateur (non represents) invoque depuis son 
navigateur "WEB" (figure 3:10) une "URL" qui peut se presenter de la facon 
suivante : 

"http://@carte:8080/xxx.html" (3), 
dans laquelle "@carte" est une adresse IP de la carte a puce (par exemple 
I'adresse de rebouclage "127.0.01" precedemment decrite : voir formule (1)), et 
"xxx.html" est une page en langage "HTML" relative a une application 
particuliere "xxx" offerte par la carte a puce. 
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Lors d'une deuxieme etape, de la maniere decrite precedemment, la carte a 
puce renvoie une page "HTML", par exemple de type formulaire. 
Lors d'une troisieme etape I'utilisateur renseigne les champs du formulaire et 
en transmet le contenu a la carte a puce, habituellement en cliquant sur un 
champ particulier, de type "bouton poussoir". 

Les donnees sont alors emises et recues par I'agent reseau 132. Les donnees 
traversent alors le multiplexeur de paquets 130 (qui constitue I'un des 
composants de la couche specifique 13, cote terminal 1), le gestionnaire 
d'ordres "APDU" 102, les couches protocolaires 101, pour etre transmises a la 
carte a puce 2a. Elles traversent ensuite les couches protocolaires 200a, le 
gestionnaire d'ordres "APDU" 201a, le multiplexeur de paquets 230a pour etre 
recues par I'agent "WEB" 232ai. II s'etablit done une session logique entre les 
deux agents intelligents, comme explicite precedemment. 

II convient de remarquer que les donnees adressees a I'agent "WEB" 232ai 
sont transportees, de facon conventionnelle en soi, sous formes d'ordres 
"APDU" destines a I'application particuliere "Multiplexeur de paquets". Le 
gestionnaire d'ordres "APDU" 201a selectionne cette application de maniere 
tout a fait similaire aux autres applications de type "CGA" presentes dans la 
carte a puce 2a, referencees A\ a An. En d'autres termes, le multiplexeur de 
paquets 230a est vu par le gestionnaire d'ordres "APDU" 201a comme une 
application "CGA" ordinaire. 

La requete "HTTP" est analysee par I'agent "WEB" 232ai qui detecte une 
reference a un repertoire particulier, que Ton appellera ci-apres par convention 
"cgi-smart", d'une part, et a une application particuliere, par exemple "xxx" dans 
le cas de I'exemple decrit, d'autre part. Le chemin complet est done, en 
I'occurrence "cgi-smart/xxx". 

Selon une caracteristique importante du procede de I'invention, I'entite ci- 
dessus designe un script particulier associe a une application egalement 
particuliere "xxx". 
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Lors d'une quatrieme etape, le script est interprets par un agent intelligent dit 
"Agent traducteur de script", que I'on appellera "ATS" ci-apres. Cette traduction 
peut etre realisee de differentes manieres : 

a/ par I'agent "WEB" 232ai lui-meme, qui est dote dans ce cas d'une double 
capacite ; 

b/ par un agent traducteur de script unique capable de traduire I'ensemble 
des scripts presents dans la carte a puce 2a ; 

d par un agent de script dedie que Ton appellera "ATSD" ci-apres (un par 
script) ; ou 

d/ par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, qui 
est dote, dans ce cas, d'une double capacite. 

L'agent "APDU" 2010a est une composante de la couche gestionnaire d'ordres 
"APDU" 201a. Cette derniere, comme il a ete indique, est une couche capable 
de centraliser tous les ordres "APDU" emis et/ou recus par le systeme, de 
selectionner des applications, parmi A\ a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon I'une des 
caracteristiques du precede, de communiquer avec tous les agents intelligents 
du systeme (via des sessions), que ces agents soient localises dans le terminal 
1 ou la carte a puce 2a. 

Dans le cas d ci-dessus, une session est ouverte entre I'agent "WEB" 232ai 
et Tun des agents "ATSD". 

La figure 4 illustre un exemple d'architecture pour laquelle les agents 
traducteurs sont du type "ATSD". lis sont references ATS1 a ATSn et associes 
aux applications Ai a A n . L'application selectionnee etant supposee etre 
I'application Aj, la session s'etablit entre I'agent "WEB" 232ai et I'agent ATSj. 

Un agent traducteur de script genere une suite d'ordres "APDU". Une session 
est ouverte entre I'agent traducteur, par exemple I'agent ATS\, et I'agent 
"APDU" 2010a. Les ordres sont alors emis vers I'agent "APDU" 2010a. Le 
gestionnaire d'ordres "APDU" 201a selectionne l'application "CGA" Aj (par 
exemple I'application "PME") et lui transmet les ordres "APDU", ordres traduits 
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et done conventionnels, qu'elle est en mesure de comprendre. Cette 
application est done correctement activee, sans avoir a la modifier ou a la 
reecrire. 

Les reponses de I'application "CGA" Aj sont transmises au gestionnaire 
d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de nouveau a I'agent 
ATSj (et de facon plus generale a I'agent traducteur de script). 

En fonction de la reussite ou de I'echec du deroulement du script, I'agent 
traducteur de script, par exemple I'agent ATSj dans I'exemple de la figure 4, 
elabore une page en langage "HTML" et la transmet via les differentes couches 
empruntees par la requete initiate, mais en sens inverse, ce pour etre 
presentee sur I'ecran de visualisation 5 (figure 1A). 

Les differents cheminements sont represents symboliquement sur la figure 4 
par des traits pleins reliant les blocs fonctionnels ou en pointilles a I'interieur de 
ces blocs. 

La figure 5 resume de facon schematique les principals etapes du processus 
qui vient d'etre decrit : 

a/ transmission via le reseau Internet Rl (ou a partir du terminal local : dans 
les deux cas a I'aide d'un navigateur conventionnel 10) d'une requete "HTTP", 
referencee RQ ; 

b/ reponse du serveur "WEB" de la carte a puce 2a, sous la forme d'un 
formulaire, reference FO ; 

d transmission du formulaire rempli, sous la forme d'une nouvelle requete 
RQ;et 

d/ reponse sous la forme d'une page "HTML", referencee PR. 

La reponse pourrait d'ailleurs consister en la transmission d'un fichier, ou 

d'une piece de logiciel ou "Applet". 

En mettant en ceuvre les mecanismes et fonctions qui viennent d'etre decrits, 
notamment la fonction serveur "WEB" et le recours a des agents intelligents 
traducteurs de scripts, selon une caracteristique essentielle, le precede selon 
I'invention va permettre de definir un environnement virtuel, avantageusement 
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securise par la carte a puce. Dans un mode de realisation preTere, cet 
environnement est compatible avec les applications de type dit multimedia. 
Cette derniere caracteristique est particulierement avantageuse car les 
navigateurs "WEB" recents, mais de type tout a fait classique en soi, 
permettent, par nature, de construire des environnements multimedias (images 
animees, sons, etc.). lis sont en effet associes a des outils logiciels, integres 
ou non, permettant de manipuler des fichiers multimedia (visionneuse, etc.). En 
tout etat de cause, les navigateurs permettent de telecharger des fichiers de 
donnees multimedias, habituellement volumineux et de les stocker sur un 
disque dur, par exemple dans le terminal, ou sur un organe de stockage de 
masse similaire. On a notamment propose des technologies permettant 
I'affichage en temps reel ou quasi-reel de sequences videos ou la reproduction 
de son, a partir de sites "WEB" du reseau Internet. 

Cependant, une carte a puce, comme il a ete rappele, ne presente qu'une 
faible capacite de memoire. En outre, elle n'autorise qu'un tres faible debit de 
donnees lors des echanges. II n'est done pas possible d'enregistrer un grand 
nombre de fichiers de donnees dans celle-ci. II n'est pas non plus 
envisageable, de facon pratique, de stocker des fichiers multimedias, a 
I'exception de tres courtes sequences ou de sequences sonores codees sous 
un format particulier, tel que le codage "MIDI". 

En dehors de ces limitations d'ordre technologique, il est aussi souhaitable de 
pouvoir avoir acces a des applications eloignees, tout en beneficiant d'une 
securisation de haut niveau, que seule la mise en ceuvre d'une carte a puce est 
apte a offrir. 

Le precede selon I'invention permet ce mode de fonctionnement. 
L'environnement virtuel multimedia securise par carte a puce, selon un mode 
de realisation prefere, permet de : 

definir des objets virtuels auxquels la carte a puce peut acceder ; 

fournir des methodes d'acces a ces objets. 
La figure 6 illustre schematiquement cet aspect essentiel du precede selon 
I'invention. 
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Un utilisateur Uj interroge la carte a puce 2a grace au navigateur "WEB" 10 
compris dans le terminal 1 . Selon un mecanisme qui va etre precise ci-apres, 
grace notamment a la fonction "serveur WEB" precedemment decrite, la carte a 
puce 2a va renvoyer au navigateur une liste d'objets dits virtuels Obvj, i etant 
un indice arbitraire, auquel il a acces, c'est-a-dire de facon pratique pour 
lesquels la carte a puce 2a ou I'utilisateur Uj possede des droits d'acces. En 
effet, ces droits d'acces peuvent etre lies strictement a la carte a puce 2a et 
immuables. lis peuvent egalement etre lies a un profil utilisateur, I'utilisateur Uj 
fournissant, par exemple, des donnees ^identification et un mot de passe. La 
carte a puce 2a effectue une verification par comparaison avec des donnees 
d'une base de donnees de securite enregistrees dans une memoire fixe et, si le 
resultat de la comparaison est positif, fournit une liste d'objets virtuels Obvj 
associee au couple : "donnees ^identification - mot de passe". De facon 
connue en soi, cette premiere phase peut mettre en oeuvre un procede de 
chiffrage des donnees echangees entre le terminal et la carte a puce 2a ou 
mettre en oeuvre un protocole de transmission securise "HTTPS". La carte a 
puce 2a va egalement fournir une liste de methodes d'acces aux objets virtuels 
Obvj. 

Les objets virtuels Obvj, qui sont de type statique ou dynamique comme 
indique precedemment, peuvent etre localises indifferemment dans la carte a 
puce 2a, ou dans le terminal 1 , ou, de facon plus generate, dans un systeme 
quelconque connecte au reseau Internet Rl. Selon une caracteristique 
importante de I'invention, cet emplacement est "transparent" pour le navigateur 
10, et done pour I'utilisateur Ui, comme il va I'etre montre. 

Le procede selon I'invention fait appel notamment a ce qui va etre appele ci- 
apres un systeme de gestion de fichier virtuel, ou "SGFV", et un agent 
intelligent traducteur de script specialise, que Ton appellera "ATSDA/SGVF", 
dedie a cette tache. Cet agent intelligent fournit la liste des objets virtuels Obvj 
auxquels la carte a puce 2a peut acceder. Une adresse "URL" particuliere est 
associee a chaque objet virtuel Obvj. L'invocation de cette "URL" depuis le 
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navigateur "WEB" 10 permet d'instancier I'objet virtue! Obv/, au moyen d'une 
methode d'appel determine, specifique ou non a cet objet. 
On va tout d'abord rappeler brievement les principales caracteYistiques d'un 
systeme de gestion de fichiers classique, appele ci-apres "SGF". Un tel 
systeme est utilise pour stocker de I'information sur un support tel qu'un disque 
dur. L'information est memorisee sous la forme d'un fichier. Un fichier, que ce 
soit des donnees pures ou des instructions de programme, est compose 
classiquement d'une suite de blocs de taille fixe. Un mecanisme bien connu 
permet d'obtenir la liste des blocs de memoire qui constitue le fichier et leurs 
adresses dans la memoire. 

Un repertoire est un fichier particulier dont le contenu est une liste de 
descripteurs de fichier. Un tel descripteur comprend par exemple les elements 
suivants : 

le nom du fichier ; 

la longueur du fichier ; 

la date de creation ; 

une reference permettant de retrouver la liste des blocs du fichier 
(numero du premier bloc, tableau des numeros de blocs, etc.) ; et 

et des attributs qui specifient des proprietes particulieres du fichier 
(repertoire, lecture, ecriture, execution, etc.). 

Le premier repertoire est habituellement appele repertoire racine. Un 
repertoire qui n'est pas racine est dit sous-r6pertoire. Le repertoire qui contient 
le descripteur d'un fichier donne est son repertoire pere. L'adresse d'un fichier 
dans le "SGF" est done une succession de noms de repertoires, depuis le 
repertoire racine jusqu'au repertoire pere du fichier, ce qui definit un chemin. A 
titre d'exemple, un tel chemin se pr^sente comme suit : 

"/racine/repertoirel /r6pertoire2/nom_du_fichier" (4), 
les chiffres 1 et 2 etant arbitrages, "racine" etant le nom du repertoire racine et 
"nom_de_fichier" un nom quelconque de fichier. 

Pour une carte a puce, la norme ISO 7816-4 definit le repertoire racine dit 
"MF" (pour "Master File" ou fichier maitre), des sous-repertoires dits "DF" (pour 
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"Dedicated Files" ou fichiers dedies) et des fichiers elementaires dits "EF" 
(pour "Elementary Files). 

Dans le cadre de I'invention, le systeme de gestion de fichiers "SGFV", que 
Ton appellera virtuel, permet de definir des objets virtuels Ob vj auxquels la 
carte a puce 2a peut avoir acces. Selon le procede de I'invention, un objet 
virtuel Obvj est associe a un fichier elementaire virtuel. Le contenu d'un fichier 
elementaire virtuel est constitue par I'ensemble des informations qui permettent 
d'acceder a I'objet virtuel associe Obvj et d'en obtenir une instance dans le 
terminal 1 . 

De facon pratique, comme illustre schematiquement par la figure 7, le systeme 
"SGFV" peut constituer un sous-ensemble d'un systeme "SGF" classique, et, 
de facon plus precise, un "SGFV" est loge a I'interieur d'un fichier elementaire, 
tel que definit par la norme ISO 7816-4 precitee. 
Un descripteur de fichier comportera generalement les elements suivants : 
le nom du fichier ; 
la longueur du fichier ; 
la date de creation ; 

une reference (avantageusement un nombre entier) qui permet de 
retrouver la liste des blocs du fichier (numero du premier bloc, tableau de 
numeros de blocs, etc.) : un fichier virtuel est identifie par son nom ou cette 
reference unique ; et 

des attributs du fichier qui specifient les references particulieres du fichier 
: repertoire ou fichier elementaire, virtuel ou non virtuel, direct ou indirect. 

On appelle "objet virtuel direct", un objet qui est instancie depuis la 
carte a puce 2a. II s'agit typiquement d'un objet virtuel Obvj statique qui peut 
etre manipule par le navigateur, par exemple affiche (image, etc.). On appelle " 
objet virtuel indirect", un objet virtuel Obvj qui est instancie depuis le navigateur 
10, typiquement a I'aide d'un "applet". 

La figure 8 illustre schematiquement I'architecture d'un systeme a 
carte a puce permettant d'instancier un objet virtuel Obvj localise a un endroit 
quelconque du reseau Internet Rl, via le navigateur 10 et la carte a puce 2a. 
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Les elements communs aux figures prec6dentes portent les memes references 
et ne seront re-decrits qu'en tant que de besoin. 

[.'architecture illustree sur la figure 8 est tres similaire a celle de la 
figure 4. La difference essentielle est constitute par le fait que Ton a prevu un 
"SGFV" 8, stocke dans la carte a puce 2a, et un agent intelligent traducteur de 
script specifique "ATSDA/SGFV", reference 7. Le mode de fonctionnement est 
similaire a celui illustre par la figure 4 lorsque Ton desire acceder a une 
application particuliere Aj. II est done inutile de le re-decrire en detail. Dans le 
cas present I'application particuliere est remplacee par le systeme de gestion 
de fichuer virtuel "SGFV" 8. On etabiit tout d'abord une session entre I'agent 
intelligent reseau 132 et I'agent intelligent "WEB" 232ar Selon le mecanisme 
precedemment explicite, il s'etablit ensuite une session entre I'agent 
"WEB" 232ai et I'agent intelligent "ATSDA/SGFV" 7. 

De facon pratique, I'agent intelligent "ATSDA/SGFV 7 est accessible 
par des "URL", typiquement du type : 

"http://www.host.com/cgi-smart/sgfv?" (5), 
dans lesquelles "sgfv" est une application de type "CGI" associee a I'agent 
intelligent "ATSDA/SGFV 7. La requete ci-dessus permet de parcourir I'arbre 
des repertoires et de "montrer" leur contenu au navigateur 10, au moyen d'une 
page "HTML". Les "feuilles "de I'arbre sont des fichiers elementaires, virtuels 
ou non virtuels, associes a un hyperlien. La transmission dans le sens "carte a 
puce 2a - terminal 1" est realisee de la maniere qui a ete explicitee en regard 
de la figure 4. 

En d'autres termes, I'agent intelligent "ATSDA/SGFV 7 associe a tout element 
du "SGFV 8, repertoire ou fichier elementaire, une adresse "URL". L'adresse 
"URL" d'un repertoire designe une page "HTML" qui contient la liste de ses 
elements. L'adresse "URL" d'un fichier elementaire permet de cr6er une 
instance de I'objet virtuel Obvj associe a ce fichier virtuel. 
Pour fixer les idees, si on utilise l'adresse "URL" (5) ci-dessus, on obtient une 
page "HTML" qui presente le contenu du repertoire racine au navigateur 10. Ce 
repertoire racine est constitu6 par un ensemble de sous-repertoires et de 
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fichiers comme illustre schematiquement par la figure 9. Sur cette figure, on a 
represents un repertoire racine rep#0, au niveau superieur, un fichier 
elementaire reel fe#7 et un sous-repertoire reel srep#1, au niveau 
immediatement inferieur, et un sous-repertoire virtuel rep#2 et un fichier 
elementaire virtuel fe#5, au niveau le plus bas, tous deux dependants du sous- 
repertoire reel srep#1 , les numeros de reference etant purement arbitraires . 

Lors d'une premiere phase, I'agent intelligent "ATSDA/SGFV" 7 
transmet au navigateur 10, en reponse a la requete recue, une page "HTML" 
(non representee) montrant, sous une forme ou une autre, la structure 
hierarchique du "SGFV" 8. La page est habituellement affichee sur un ecran de 
visualisation (figure 1A : 5), par exemple sous la forme d'un menu. Chaque 
ligne du menu est constitute d'un hyperlien decrivant un sous-repertoire ou un 
fichier elementaire. L'affichage peut etre avantageusement sous forme 
graphique, associee ou non a un texte descriptif, le dessin de I'arbre de la 
figure 9 etant affiche sur I'ecran precite. On peut encore afficher des ic6nes ou 
des formes complexes (par exemple en 3 dimensions), chacune etant associee 
a I'un des objets virtuels a instancier, et pouvant etre representative de leur 
nature (a titre d'exemple, une camera representant un fichier video), associee 
ou non a un texte descriptif. 

L'utilisateur C//est invite a cliquer sur un hyperlien (sur un noeud ou sur 
une branche dans le cas d'un graphique). Par cette action, il va pouvoir obtenir 
une instance de I'objet virtuel Obvj desire. 

Le systeme "SGFV" 8 est avantageusement enregistre dans une memoire de 
type re-programmable comprise dans la carte a puce 2a, par exemple du type 
"EEPROM" (memoire effacable electriquement), comme illustre 
schematiquement sur la figure 10. Le "SGFV" 8 reproduit la structure de I'arbre 
de la figure 9. 

Toujours dans I'exemple decrit, une fois obtenu la page de menu, 
obtenue lors d'une phase initiate, en cliquant sur une "URL" qui pourrait etre 
typiquement la suivante : 

"http://www.host.eom/cgi-smart/file#5 (6), 
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I'utilisateur Uj obtient une instance de I'objet virtuel Obvs associe au fichier 
elementaire reference fe#5 sur la figure 10. De meme, il aurait pu obtenir le 
contenu d'un sous-repertoire, le parametre "file#5" etant remplace par "///e#x" 
dans (6), #x etant le numero associe au sous-repertoire. 

Les fichiers non virtuels sont enregistres dans la carte a puce 2a et 
sont conformes au paradigme usuel qui gouverne les "SGF". lis contiennent 
des donnees, telles que par exemple des cles, donnees utiles a I'agent 
intelligent "ATSDA/SGFV" 7. 

Differentes conventions sont possibles quant a la definition des 
informations necessaires a I'instanciation d'un objet virtuel Obvj, et par exemple 

un fichier virtuel de longueur nulle herite des methodes d'acces de son 
repertoire pere ; 

un repertoire virtuel est associe a un fichier elementaire virtuel dont le 
nom est impose (par exemple "virtual"), et qui contient les methodes d'acces de 
ce repertoire. 

En effet, outre la liste des objets virtuels accessible Obvj, un agent 
intelligent "ATSDA/SGFV" 7 doit egalement fournir une methode d'acces a un 
objet virtuel donne Obvj, ce a partir de tout ou partie des informations 
contenues dans un fichier virtuel elementaire. La figure 11 illustre 
schematiquement ce processus. 

Selon le procede de I'invention, on prevoit deux methodes d'acces, 
que Ton appellera directe et indirecte, respectivement, en fonction des attributs 
du fichier elementaire virtuel considere. 

La methode directe consiste en une description d'une chaine d'agents 
intelligents mis en oeuvre dans le processus permettant d'acceder a un objet 
virtuel Obvj et d'en obtenir une instance dans le terminal. Lors de I'ouverture 
d'une session, un agent intelligent donne recoit, de I'agent qui initie cette 
session, une liste de structures d'appel qui sera denommee ci-apres "methode 
d'appel" ou encore "Method PDU" (pour "Method Protocol Data Unit"). 
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Une structure d'appel comprend : 

- un identificateur de I'agent intelligent avec lequel la session est ouverte ; 

- des donnees, ou argument, necessaires a son utilisation. 

Le premier agent intelligent adresse par la liste precitee "consomme" 
une premiere structure d'appel qui lui est destinee. II transmet le reste de la 
liste de structure a un agent intelligent suivant, avec lequel il etablit une 
session, jusqu'a epuisement de la liste. 

Pour fixer les idees, un exemple des differentes etapes d'echanges 
entre I'agent intelligent "ATSDA/SGFV" 7 et deux agents intelligents en 
cascade, 232am et 232an, est illustre schematiquement par la figure 12. La 
liste de structure d'appel emise par I'agent intelligent "ATSDA/SGFV" 7 
comporte en realite deux sous-listes distinctes, reperees #1 et #2 dans leurs 
en-tetes, respectivement. La premiere est consommee par le premier agent 
intelligent, 232am, et la seconde par le second agent intelligent, 232an- Un 
agent intelligent, par exemple I'agent intelligent 232am, est identifie par une 
reference, ou identificateur d'agent ("Identificateur Agent #1" ou "Identificateur 
Agent #2"). L'agent intelligent adresse, et avec lequel s'etablit une session, 
retient la sous-liste qui lui est destinee grace a I'en-tete ("Structure d'Appel #1 
ou "Structure d'Appel #2"). Les arguments de la sous-liste qu'il retient 
("Argumentttr ou "Argument#1") sont constitues par un ensemble de donnees 
utiles au bon fonctionnement de cet agent. A titre d'exemple, une donnee peut 
etre un nom de fichier (non virtuel ou virtuel direct). 

Un agent intelligent donne, par exemple I'agent intelligent 232am, peut 
modifier le reste de la liste de structure d'appel avant de la transmettre a 
I'agent intelligent suivant, 232an. Pour ce faire, il adresse cet agent intelligent, 
232an, et etablit une session avec lui. 

La methode d'appel peut etre avantageusement decrite au moyen du 
langage ASN.1 (Abstract Syntax Notation 1" de I'lSO) 

La methode d'acces directe permet en definitive d'instancier un objet 
virtuel Obvj directement depuis la carte a puce 2a. II s'agit a priori d'un objet 
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statique. L'objet instance se presente habituellement sous la forme d'une page 
"HTML" ou d'un "applet" transmis au navigateur 10. 

La seconde methode d'acces, ou methode d'acces indirect, est en realite 
egalement une methode d'acces direct, mais mise en oeuvre a partir du 
terminal 1 , et non plus de la carte a puce 2a. Cette methode est 
essentiellement utilisee pour instancier des objets virtuels Obvj du type 
dynamique. 

Selon cette variante du procede, en reponse a un "URL" qui designe un fichier 
elementaire virtuel fe#x, I'agent intelligent "ATSDA/SGFV" 7 transmet au 
navigateur 10 une page "HTML" qui comporte un hyperlien pointant sur la 
methode d'acces directe associee a l'objet virtuel Obvj 
Deux variantes peuvent etre mises en ceuvre. 

La premiere variante consiste a utiliser un "applet". Le lien sur la methode 
d'acces est alors un "applet" localise a I'adresse "@carfe", qui peut elle-meme 
etre designee par : 

le nom (c'est-a-dire une "URL") d'un fichier non virtuel, enregistre sur la 
carte a puce 2a ; 

une "URL" qui designe un fichier virtuel direct. 
Un parametre d'appel de cet "applet" est une liste de structure d'appel, par 
exemple codee en ASN.1 comme indique ci-dessus. L' "applet" contenu dans 
une page "HTLM" est telecharge, depuis la carte a puce 2a ou le reseau 
Internet Rl, vers le navigateur 10, puis execute par celui-ci de facon obligatoire 
(forcage). Cet "applet" etablit une session avec un premier agent intelligent, 
arbitrairement reference 232ap. La connexion a cet agent intelligent 232ap 
utilise, par exemple, un modele d'echange de donnees du type dient-serveur 
'TCP/IP" (c'est-a-dire la classe dite "socket JAVA"). U "applet" se comporte 
comme un client 'TCP/IP" et se connecte a un serveur "TCP/IP" (ce dernier 
etant egalement un agent intelligent) identifie par I'adresse de la carte et un 
port : "@carte : port". 

La figure 13 illustre schematiquement les differentes phases des echanges 
permettant d'instancier un objet virtuel par la methode indirecte. On a repris sur 
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cette figure 13 les parametres de I'exemple precedemment decrit, en 
I'occurrence, le fichier elementaire virtuel fe#5, ce qui se traduit par I'adresse 
"URL" de la configuration (6) ci-desus. On a suppose que I'adresse de la carte 
a puce a utiliser est "@carfe" et le port 8080. La requete est transmise a I'agent 
intelligent "ATSDA/SGFV" 7 selon le processus precedemment decrit. Celui-ci 
renvoie au navigateur 10 une page "HTML" P constitute par un "applet". Dans 
un but de simplification du dessin, les differentes instructions de cet "applet" 
ont ete resumees sur la figure 1 3 par la mention "CODE applet' placee entre 
les marqueurs <applet ...> et </applet>. De facon connue en soi, I" "applet" est 
associe a une classe "JAVA", que Ton a appele arbitrairement "tv.class", pour 
"terminal virtuel". Le code comprend egalement des instructions indiquant 
I'adresse du premier agent intelligent de la structure de liste , reference 232ap, 
et I'adresse et le port a utiliser, en I'occurrence I'adresse "@ca/fe" et le port 
8081. II est a noter que cet agent intelligent 232ap peut etre localise dans la 
carte a puce 2a ou dans le terminal 1 . 

Chaque agent intelligent, par exemple 232ap, execute une tache precise : 
dechiffrement d'un message chiffre, verification de mots de passe et/ou de 
donnees de securite, conversion d'un fichier, d'un format a un autre, etc. Bien 
que I'on ait represente qu'un seul agent intelligent, 232ap, comme dans le cas 
precedent (figure 12) on peut prevoir, en tant que de besoin, plusieurs agents 
intelligents en cascade. Comme precedemment egalement chaque agent 
intelligent, 232ap, consomme une partie de la structure de liste, celle qui lui est 
destinee, et transmet le reste, inchange ou modifie, a I'agent intelligent suivant 
(non represente). 

Pour mieux illustrer la premiere variante, et pour fixer les idees, on va 
considerer que I'utilisateur Uj desire telecharger et executer un fichier audio, 
code par exemple au format "MP3". Ce fichier constitue Tun des objets virtuels, 
ici reference FS, proposes par la page de menu "HTML" transmise par I'agent 
intelligent "ATSDA/SGFV" 7, lors de la phase initiate. La figure 14 illustre 
schematiquement la sequence d'etapes permettant d'instancier un tel objet 
virtuel, reference FS. On suppose que le navigateur 10 ne dispose pas d'un 



2791159 



33 

lecteur approprie pour un tel format. Ce lecteur, reference LS, va etre cherche 
sur un site Internet, qui peut etre distinct ou non du site ou se trouve le fichier 
son FS. 

Dans I'exemple decrit, la sequence d'6tapes est la suivante. 

a/ I'utilisateur U, clique sur un hyperlien (texte, ic6ne ou toute autre 
representation graphique de I'objet a rechercher, c'est-a-dire le fichier FS) : 
une requete /1 est transmise a la carte a puce 2a ; 

b/ en reponse, Ri , une page "HTML" est transmise, par la carte a puce 2a, 
au terminal 1 et au navigateur 10 ; 

c/ la page "HTML" recue force le navigateur 10 a demander un "applet" : 
interrogation /2 (dans le cas present, il s'agit d'aller chercher le lecteur de son 
approprie LS) ; 

d/ en reponse, R2, le lecteur recherche LS est telecharge et installe dans le 
terminal 1 ; 

el le navigateur 10 adresse de nouveau la carte a puce 2a, requete /3, en 
vue d'obtenir une instance du fichier audio FS; et 

V en reponse, le navigateur 10 recoit ce fichier audio FS, ce dernier 
pouvant etre lu, c'est-a-dire joue par le terminal 1 , qui dispose desormais du 
lecteur de son LS approprie. 

II est a noter que toutes les operations sont transparentes pour I'utilisateur Uj, 
plus precisement pour le navigateur 10, qui ne "connait" que la carte a puce 
2a. Le lecteur LS (ou de facon plus generate un autre "applet") et/ou I'objet 
virtuel recherche, c'est-a-dire le fichier FS dans I'exemple, si leurs tallies 
avaient ete compatibles avec la capacite de memorisation de la carte a puce 
2a, auraient d'ailleurs pu etre enregistres dans celle-ci (re-bouclages 
symbolises par des traits en pointilles sur la figure 14). Le navigateur 10 ne 
connait pas la localisation exacte des objets virtuels Obvj. Seule la carte a 
puce 2a, de facon plus precise I'agent intelligent "ATSDA/SGFV" 7, connait la 
localisation des objets virtuels de la liste du "SGFV" 8 et la methode pour y 
acceder. 
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Dans une variante preferee du precede, I'agent intelligent "ATSDA/SGFV" 7 
connait egalement la liste des seuls objets virtuels accessibles a un utilisateur 
Uj donne (autorisations). II s'agit done bien d'un systeme securise. Le terme 
"securise" doit etre considere dans son sens le plus large. A titre d'exemple, il 
concerne aussi bien des cartes a peage donnant acces a certaines ressources, 
en fonction d'un abonnement determine par exemple, ou des cartes assurant 
un acces securise proprement dit a des ressources confidentielles, en fonction 
d'un niveau d'habilitation par exemple. Comme il a ete indique, les ressources 
ou objets virtuels Obvj peuvent etre constitutes par des transactions. 
Ces remarques s'appliquent d'ailleurs aussi pour les methodes d'acces direct. 
Cela constitue une caracteristique tres importante du procede selon I'invention. 
Selon une seconde variante, illustree schematiquement par la figure 15, on 
peut utiliser un hyperlien qui definit I'adresse 'TCP/IP" du premier agent 
intelligent associe a la methode d'acces. I'adresse est du type : 
"@Agent:AgentPort", avec "@Agent", I'adresse proprement dite de I'agent 
intelligent concerne et "AgentPort" le port de celui-ci. La liste "MethodPDU" est 
dans ce cas un parametre d'une "URL". L'hyperlien sera associe, par exemple 
a une image ou un formulaire d'une page "HTML" P'. 
Ainsi, a titre d'exemple, une "URL" ayant la structure suivante : 

http://@Agent:AgentPort/MethodPDU?Value=xx... (7), 
permet d'atteindre un agent intelligent qui se comporte comme un serveur 
"WEB TCP/IP", reference arbitrairement 2323^ Cet agent intelligent 232ag est 
localise a I'adresse "@Agent:AgentPort" et recoit la liste de structure d'appel 
"MethodPDU", avec le parametre "Value=xx...". 

Pour fixer les idees, on suppose que I'objet virtuel Obvj est une image a 
afficher sur un ecran (figure 1A :5), d'un format particulier, a I'aide du 
navigateur 10 et que celui-ci ne dispose pas d'un programme approprte pour 
cet affichage, generalement appele visionneuse ou "viewer" selon la 
terminologie anglo-saxonne. II s'agit, par exemple, d'un programme executable 
sous le systeme d'exploitation utilise sur le terminal 1, de type "XXX.exe", avec 
"XXX" le nom de ce programme. L'action de cliquer sur l'hyperlien (7) ci-dessus 
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va permettre de rechercher ce programme executable, celui-ci pouvant etre 

localise dans le terminal 1 ou dans un systeme eloigne. 

La difference entre les deux variantes de realisation est que dans le premier 

cas, le navigateur se voit "force" de demander le chargement d'un "applet". 

Toutes les etapes sont realisees automatiquement. Dans le second cas, 

I'utilisateur Uj est invite a cliquer sur un hyperlien ou a executer une action 

similaire. 

A la lecture de ce qui precede, on constate aisement que I'invention atteint 
bien les buts qu'elle s'est fixes. 

II doit etre clair cependant que I'invention n'est pas limitee aux seuls exemples 
de realisations explicitement decrits, notamment en relation avec les figures 2 
a 15. 

En particulier, comme en ce qui concerne les autre agents intelligents 
traducteurs de script; la fonction de I'agent intelligent associe au systeme de 
gestion de fichier virtue! peut etre remplie par un agent non dedie : I'agent 
"WEB" ou I'agent "APDU". 
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REVENDICATIONS 

1. Precede pour acceder a un objet localise dans un systeme 
informatique connecte a un reseau de type Internet par I'intermediaire d'un 
navigateur de type "WEB", ledit navigateur etant compris dans un terminal, 
muni d'un lecteur de carte a puce et connecte audit reseau de type Internet, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

- a/ une premiere phase preliminaire consistant a implanter, dans ladite carte 
a puce (2a), une premiere piece de logiciel (23a), formant une couche 
protocolaire de communication specifique ; 

- b/une deuxieme phase preliminaire consistant a implanter, dans ledit 
terminal (1), une seconde piece de logiciel (13), formant une couche 
protocolaire de communication specifique et formant interface avec au moins 
ledit navigateur "WEB" (10) ; 

- en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132,232a) cooperant I'une 
avec I'autre de manidre a permettre I'etablissement d'une session d'echanges 
de donnees bidirectionnels entre ledit terminal (1) et ladite carte a puce (2a), 
de maniere a ce que ladite carte a puce (2a) offre la fonctionnalite d'un serveur 
"WEB" ; 

- en ce qu'il est procede a une troisieme phase preliminaire consistant en 
I'implantation dans ladite carte a puce (2a) d'un systeme de gestion de fichiers 
dit virtuel (8), organise en repertoires (rep#0), sous-repertoires (srep#1, 
srep#2) et fichiers elementaires (fe#7, fe#5), une partie au moins desdits 
fichiers elementaires etant constitues par des fichiers elementaires dits virtuels 
(fe#5), associes chacun a I'un desdits objets (obw) et contenant des donnees 
de description permettant au moins de localiser celui-ci et de generer des 
donnees constituant une methode d'acces ; 

- en ce qu'il comprend une quatrieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite logicielle 
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(7), apte a interpreter une suite d'instructions et a la traduire en une suite 
d'ordres, de maniere a cooperer avec ledit systeme de gestion de fichiers 
virtuel (8) et ladite seconde piece de logiciel specifique (23a) ; 
- et en ce qu'il comprend au moins !es etapes suivantes : 

- 1/ etablissement d'une session d'echanges de donnees entre ledit terminal 
(1) et ladite carte a puce (2a), par I'intermediaire d'une desdites paires de 
premieres entites logicielles appariees (132, 232ai), de maniere a transmettre 
une requete destinee a ladite deuxieme entite logicielle (7) cooperant avec 
ledit systeme de gestion de fichiers dit virtuel (8) ; 

- 2/ elaboration et transmission audit navigateur "WEB" (10), par 
I'intermediaire de ladite deuxieme entite logicielle (7), et via lesdites premiere 
(13) et seconde (23a) pieces de logiciel, d'une reponse a ladite requete 
comprenant une liste desdits objets (Obvi) accessibles via ladite carte a puce 
(2a); 

- 3/ selection par ledit navigateur "WEB" (10) d'un desdits objets accessibles 
et envoi a ladite deuxieme entite logicielle (7) d'une requete pour obtenir une 
instance de celui-ci dans ledit terminal ; 

- 41 generation par ladite entite logicielle (7) desdites donnees constituant une 
methode d'acces, en fonction desdites donnees de description ; et 

- 5/ recherche dudit objet (Obvj) par utilisation desdites donnees de 
localisation et de methode d'acces, et creation d'une instance de cet objet 
(Obv/) dans ledit terminal (1). 

2. Procede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donnees, definies 
par la norme ISO 7816, chacune comprenant au moins des couches 
protocolaires de communication logicielles (101, 200a), dites basses, de 
maniere a permettre lesdits echanges de donnees entre ladite carte a puce 
(2a) et ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel specifique formant lesdites couches 
protocolaires de communication specifiques, respectivement, et en ce que ces 
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pieces de logiciel (13, 23a) comprennent chacune deux entiles 
supplementaires constitutes d'un module de transfer! de donnees (130, 230a), 
formant interface avec lesdites couches basses (101, 200a) des premiere et 
deuxieme piles protocolaires, et d'un module de gestion (131, 231a), et en ce 
que lesdites premieres entites de chaque paire sont constitutes de modules 
logiciels, dits agents intelligents (132, 232a1) etablissant lesdites sessions. 

3. Procede selon la revendication 2, caracterise en ce que, ladite suite 
d' instructions a interpreter etant constituee par un script, ladite deuxieme entite 
logicielle (7) cooperant avec ledit systeme de gestion de fichiers virtuel (8) est 
constituee par un module logiciel dit agent intelligent traducteur de script. 

4. Procede selon la revendication 3, caracterise en ce que ledit agent 
traducteur de script (7) cooperant avec ledit systeme de gestion de fichiers 
virtuel (8) est confondu avec ledit agent intelligent (232ai) etablissant lesdites 
sessions d'echanges de donnees entre ledit terminal (1) et ladite carte a puce 
(2a). 

5. Procede selon la revendication 3, caracterise en ce que lesdites 
applications sont d'un type devant etre active a I'aide d'un jeu d'ordres dits 
"ADPU", definis par la norme ISO 7816, ledit terminal (1) et ladite carte a 
puce (2a) comprennent une entite logicielle supplemental (102, 201a), dite 
gestionnaire d'ordres "ADPU", en ce que ladite interface entre lesdites couches 
basses (101, 200a) des premiere (101) et deuxieme (200a) piles protocolaires, 
d'une part, et lesdites premiere (13) et seconde (23a) pieces de logiciel 
specifique (23a), d'autre part, s'effectue par I'intermediaire desdits 
gestionnaires d'ordres (102, 200a). 

6. Procede selon la revendication 5, caracterise en ce que ledit gestionnaire 
d'ordres (201a) de la carte a puce (2a) comprend en outre une entite logicielle 
du type agent intelligent (2010a) permettant I'etablissement d'une session 
d'echanges de donnees bidirectionnels avec d'autres agents intelligents, cet 
agent (2010a) etant dit agent intelligent gestionnaire d'ordres, et en ce que 
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ledit agent traducteur de script (7) cooperant avec ledit systeme de gestion de 
fichiers virtuel (8) est confondu avec ledit agent intelligent gestionnaire 
d'ordres (2010a). 

7. Procede selon la revendication 1, caracterise en ce que ladite deuxieme 
entite logicielle (7) cooperant avec ledit systeme de gestion de fichier virtuel (8) 
associe, a chacun desdits repertoires (rep#0), sous-repertoires (srep#1, 
srep#2) et fichiers elementaires (fe#7, fe#5), une adresse de type Internet dite 
"URL", en ce que ladite etape 21 de reponse consiste en I'envoi d'une page en 
langage "HTML" comprenant des hyperliens pointant sur lesdites adresses 
"URL", et en ce que ladite etape 3/ de selection consiste a actionner I'un de 
ces hyperliens de maniere a acceder a I'un desdits repertoires (rep#0), sous- 
repertoires (srep#1, srep#2) ou fichiers elementaires (fe#7, fe#5) ; I'acces a un 
repertoire (rep#0) ou a un sous-repertoire (srep#1, srep#2) occasionnant la 
transmission vers ledit navigateur "WEB" (10) d'une page en langage "HTML" 
presentant son contenu, et I'acces a un desdits fichiers elementaires virtuels 
(fe#5) occasionnant ladite recherche de I'objet {Obvi) associe a ce fichier 
elementaire virtuel (fe#5) et la creation d'une instance de cet objet (Obvi) dans 
ledit terminal (1). 

8. Procede selon la revendication 7, caracterise en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplemental (232am, 232a/77) 
destine a Interpretation d'un script predetermine, de maniere a remplir une 
tache predeterminee, et en ce qu'il comporte une premiere methode d'acces 
aux dits objets (Obvi), dite directe, consistant a decrire lesdits agents 
intelligents supplementaires mis en ceuvre pour acceder aux dits objets (Obv/) 
et comprenant au moins les etapes suivantes : 

- a/ creation d'une structure d'appel comprenant au moins un element, chaque 
element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232am, 232am) et des donnees, dites argument, utilisees par 
celui-ci pour I'execution de ladite tache ; 
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- b/ I'etablissement d'une session entre un premier agent intelligent 
supplemental (232a m ) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplemental 
(232an) etant selectionne par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- d lorsque ladite structure comporte plusieurs elements, etablissement d'une 
session entre ledit premier agent intelligent supplemental (232am), et un 
autre agent intelligent supplemental (232an), et transmission des elements 
restants de la structure d'appel, cet autre agent intelligent supplemental 
(232an) etant selectionne par ledit identifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- d/ repetition de I'etape cl jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

9. Procede selon la revendication 7, caracterise en ce qu'il comporte une 
seconde methode d'acces, dite indirecte, comprenant au moins une etape 
consistant, en reponse a une requete transmise par ledit navigateur "WEB" 
(10) a ladite deuxieme entite logicielle (7) cooperant avec ledit systeme de 
gestion de fichier virtuel (8), designant un desdits fichiers elementaires virtuels 
(fe#5), a transmettre au navigateur "WEB" (10) une page en langage "HTML" 
(P) comportant un hyperlien pointant sur un enregistrement comportant des 
donnees necessaires a la generation de ladite methode d'acces. 

10. Procede selon la revendication 9, caracterise en ce que ladite page en 
langage "HTML" (P) comprend une piece de logiciel en langage "JAVA", 
chargee depuis ladite carte a puce (2a) ou depuis ledit reseau de type Internet 
(R/), sous la commande dudit agent intelligent (7) cooperant avec ledit systeme 
de gestion de fichier virtuel (8), et executee par ledit navigateur "WEB" (10), de 
maniere a retrouver des donnees necessaire a la generation de ladite methode 
d'acces dans un fichier elementaire non virtuel dudit systeme de gestion de 
fichiers virtuel (8) ou par I'intermediaire d'une adresse contenue dans un 
desdits fichiers elementaires virtuels (fe#5). 
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11. Procede selon la revendication 9, caracterise en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplemental (232ap) destine 
a 1'interpretation d'un script predetermine, de maniere a remplir une tache 
predeterminee, en ce que ladite seconde methode d'acces indirect comprend 
au moins les etapes subsequentes suivantes consistant a decrire lesdits 
agents intelligents supplementaires mis en ceuvre pour acceder aux dits objets 
(Obvj) : 

- al creation d'une structure d'appel comprenant au moins un element, chaque 
element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232ap) et des donnees, dites argument, utilisees par celui-ci 
pour I'execution de ladite tache ; 

- bl I'etablissement d'une session entre un premier agent intelligent 
supplementaire (232ap) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplementaire 
(232ap) etant selectionne par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- d lorsque ladite structure comporte plusieurs elements, etablissement d'une 
session entre ledit premier agent intelligent supplementaire (232am), et un 
autre agent intelligent supplementaire (232an), et transmission des elements 
restarts de la structure d'appel, cet autre agent intelligent supplementaire 
(232an) etant selectionne par ledit identifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- d/ repetition de I'etape d jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

12. Procede selon la revendication 10, caracterise en ce qu'il est prevu au 
moins un agent intelligent traducteur de script supplementaire (232ap) destine 
a ['interpretation d'un script determine, de maniere a remplir une tache 
predeterminee, en ce que ledit hyperlien definit I'adresse d'un premier agent 
intelligent traducteur de script supplementaire (232ap), et en ce que ladite 
seconde methode comprend au moins les etapes subsequentes suivantes 
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consistant a decrire lesdits agents intelligents supplementaires mis en ceuvre 
pour acceder aux dits objets {Obvj) : 

- a/ creation d'une structure d'appel comprenant au moins un element, un 
chaque element comportant un identificateur d'un desdits agents intelligents 
supplementaires (232ap) et des donnees, dites argument, utilisees par celui-ci 
pour I'execution de ladite tache ; 

- b/ I'etablissement d'une session entre un premier agent intelligent 
supplementaire (232ap) et ledit agent intelligent (7) cooperant avec ledit 
systeme de gestion de fichier virtuel (8), cet agent intelligent supplementaire 
(232ap) etant selectionne par I'identifiant d'un premier element de ladite 
structure d'appel et retenant un element de ladite structure qui lui est destine ; 

- d lorsque ladite structure comporte plusieurs elements, etablissement d'une 
session entre ledit premier agent intelligent supplementaire {2Z2a m ), et un 
autre agent intelligent supplementaire (232a/)), et transmission des elements 
restarts de la structure d'appel, cet autre agent intelligent supplementaire 
(232an) etant selectionne par ledit identifiant et retenant un element de ladite 
structure qui lui est destine ; et 

- d/ repetition de I'etape cl jusqu'a epuisement des elements constituant 
ladite structure d'appel. 

13. Procede selon la revendication 3, en ce que ledit navigateur "WEB" (10) 
transmet a ladite carte a puce (2a), dans une phase preliminaire, une premiere 
serie de donnees de securite determinant des droits d'acces aux dits objets 
iObvi) et en ce que ladite liste des objets {Obvi) accessibles via ladite carte a 
puce (2a) est etablie, sous la commande dudit agent intelligent traducteur de 
script (7) cooperant avec ledit systeme de gestion de fichier virtuel (8), par 
comparaison avec une seconde serie de donnees de securite enregistrees 
dans une base de donnee de securite comprise dans ladite carte a puce (2a). 

14. Procede selon la revendication 13, caracterise en ce que ladite premiere 
serie de donnees de securite comprend un identifiant et un mot de passe. 
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15. Architecture pour la mise en ceuvre du proctde selon la revendication 3, 
caracterisee en ce que : 

- - ledit terminal (1) comprend au moins ledit navigateur "WEB" (10), ladite 
premiere pile protocolaire (101), et ladite premiere piece de logiciel (13) 
constituant une couche protocolaire de communication specifique, formant 
interface entre ces couches basses (101) et ledit navigateur "WEB" (10) ; et 

- - ladite carte a puce (2a) comprend ladite deuxieme pile 
protocolaire (200a), ladite seconde piece de logiciel (23a) constituant une 
couche protocolaire de communication specifique, ledit systeme de gestion de 
fichiers virtuel (8) et ladite deuxieme entite logicielle constitute par un agent 
intelligent traducteur de script (7), cette derniere formant interface entre ledit 
systeme de gestion de fichiers virtuel (8) et ladite seconde piece de logiciel 
(23a). 

16. Architecture selon la revendication 15, caracterisee en ce que ledit 
systeme de gestion de fichiers virtuel est enregistrt dans une m6moire re- 
programmable (8) comprise dans ladite carte a puce (2a). 
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